#import "myOutlineView.h"


@implementation myOutlineView

// method used to expand a particular item showing its children
- (void)expandItem:(id)item expandChildren:(BOOL)expandChildren
{
	[super expandItem:item expandChildren: expandChildren];
	[self setNeedsDisplay: YES];	// make sure the background image is redrawn (rescaled to fit the outline area)
}

// method used to collapse a particular item, hiding its children
- (void)collapseItem:(id)item collapseChildren:(BOOL)collapseChildren
{
	[super collapseItem:item collapseChildren: collapseChildren];
	[self setNeedsDisplay: YES];	// make sure the background image is redrawn (rescaled to fit the outline area)
}

/*- (void)highlightSelectionInClipRect:(NSRect)theClipRect
{
	[super highlightSelectionInClipRect:theClipRect];
	[self reloadData];
}*/


/*
* override those two methods is to resolving the problem of redraw whin resizing the window
*/
- (void)drawRect:(NSRect)rect
{
	[super drawRect:rect];
}

//- (BOOL)inLiveResize
//{
//	return NO;
//}

/*
 http://www.cocoabuilder.com/archive/message/cocoa/2008/10/4/219382
 
 I am suddenly having a load of issues with NSOutline view failing with  
 the following assertion:
 
 Assertion failure in -[NSOutlineView  
 _expandItemEntry:expandChildren:startLevel:](), /SourceCache/AppKit/ 
 AppKit-949.35/TableView.subproj/NSOutlineView.m:1003
 
 I seemed to be able to make this go away by subclassing the outline  
 view and locking it down before starting a reload or evaluating the  
 number of rows (found mostly by lots or trial and error) with the  
 following:
 
 
 - (NSInteger)numberOfRows{
 @synchronized(self){
 return [super numberOfRows];
 }
 }
 
 - (void)reloadData{
 @synchronized(self){
 [super reloadData];
 }
 }
 ===================================
 > Not explicitly, but maybe.  This seems to be taking place when the  
 > content for the NSTreeController is changing (explicitly) in one  
 > thread, causing a reload in the outline view,  and in another thread  
 > the NSOutlineView's drawrect is getting called.  I can't say for  
 > sure that this accounts for all of the cases but that seems like a  
 > common theme.
 >
 > Thoughts?
 
 
 Don't do that.
 
 You cannot change model or controller objects that are bound to in a  
 thread other than the main thread and expect things to work.  The  
 reason you can't is that Key-Value Observer notifications (the  
 foundation of bindings) are posted *around* the change, synchronously,  
 in the thread which is performing the change.
 
 It looks like you're trying to force it to work by adding  
 @synchronized blocks, but they're insufficient to do so.  This is  
 because Cocoa doesn't provide the necessary hooks into NSTableView,  
 NSTreeController or the bindings machinery where you could lock at  
 every point you'd need to.
 
 Ultimately, you need to accumulate the changes to make on your  
 background thread, and then push them to the main thread to actually  
 be applied.  If you're using Core Data and the SQLite persistent store  
 this is straightforward because each thread can use its own managed  
 object context atop the same coordinator, and saving in the background  
 thread will generate a notification that you can use to inform the  
 foreground thread to update. 
 */

- (NSInteger)numberOfRows{

    NSInteger result;
	@synchronized(self)
	{
		//NSLog(@"number begin");
        result = [super numberOfRows];
		//NSLog(@"number end");
    }
	return result;
}

- (void)reloadData{
	
    @synchronized(self)
	{
		//NSLog(@"loadData begin");
		[super reloadData];
		//NSLog(@"loadData end");
    }
		
}

@end
